Various mechanisms exist for managing execution in platforms with virtual machine environments. Existing systems tend to utilize a virtual machine monitor (VMM) to control and manage various virtual machines or guests on a platform. The VMM may be implemented with varying levels of security and control of the system resources. Communication between and among various components on a platform, while maintaining high security, can be problematic.
One platform management technique is to deploy a virtual machine monitor (VMM) on the system. There are two common architectures for virtual machine monitors. The first is a hypervisor architecture, in which a privileged hypervisor (virtual machine monitor) controls all other software in a system. The hypervisor must contain native drivers and models for all devices which it wishes to provide to software running in virtual machines (VMs) (referred to herein as guest VMs). This necessity has been a problem with this architecture of VMM. In the hypervisor architecture, the VMM has full control over the underlying platform, and may limit guest VM access to the platform hardware. The hypervisor has access to all of the hardware. A guest VM may directly access the hardware only if the hypervisor permits it. A hypervisor system may prevent guest VMs from accessing the hardware directly, if designed to do so. When the hypervisor is implemented, device drivers for each physical device must also be implemented. If the physical device changes (e.g., it is replaced by a different version of the device) then a new or replacement device driver must be present in the hypervisor. Typically, all operating systems run in VMs. The VMs may be privileged in different ways. For example, VM1 may have access to device #1 while VM2 has access to device #2.
The second common architecture for a VMM is a hosted VMM. In this architecture, the VMM is tied intimately to a hosting operating system (OS) and uses the services provided by the hosting OS to perform its virtualization functions. In this architecture, the hosting OS has full control over the platform; the VMM component has control of the platform's guest VMs. In other words, the VMM component does not directly control the underlying hardware. The VMM accesses the underlying hardware using the services provided by the hosting OS. The stability of the VMM is only as good as that of the hosting OS. The hosting OS contains all of the necessary device drivers. The VMM must implement models for all devices presented to the guest VMs. VMMs implemented with this high-level architecture suffer portability constraints because of their reliance on a particular hosting OS. Additionally, there is a reliance on the hosting OS to perform scheduling. The VMM controls scheduling of the guest VMs, but it does not control how much time it is given by the hosting OS. For instance, it may not be possible to request that the hosting OS awaken the VMM every millisecond.
Some virtualization products exist today. For instance, a hypervisor-based architecture, ESX Server, is available from VMware®, Inc. Microsoft® and VMware®, Inc. both provide host-based architecture software: Microsoft offers VirtualPC and VirtualServer, and VMWare® offers VMWorkstation and GSX Server. Currently, these software systems may be loaded on a server or personal computer (PC) that does not have hardware virtualization support.
Conventional operating systems often provide several mechanisms for applications or components to communicate with each other. Typical examples for these mechanisms are shared memory, pipes, messages or mail-boxes. To implement any security policy on top of these mechanisms, they must be extended to control communication; the two most common methods here are access controls and capabilities.
Permission can be checked at two places: at the time when a communication channel is created, modified or deleted, or secondly, every time communication takes place. Often, the checks are expensive and the only acceptable place where the impact on the communication bandwidth is limited is when a channel is modified. However, this requires that all communication channel control structures have to be maintained by the operating system.
Existing systems either do not control communication or have a very expensive rights management that is fundamental part of the host operating system. While the first case does not allow users to build a secure system, the second case has strong limitation in terms of flexibility or scalability.